Over the last decade, digital communication networks such as local area networks (LANs), wide area networks (WANs), virtual private networks (VPNs) and the Internet have increased levels of communication and access to information by an incredible degree. Wireless services over cellular telephone networks, packet data networks, wireless local loops and similar systems are now continuing the digital communications and data access revolution in a mobile environment.
In the past, wireless users could access a data system periodically to see whether email messages and other digital information had been received. These periodic checks were generally slow and complicated as the end user had to establish a new connection with his service provider each time he wanted an update (in effect, launching email software and accessing an account using a dial-up modem). This process was so slow and ineffective that many end users would simply neglect (or forget) to check their email messages from time to time.
Recently, there has therefore been great interest in the provision of “always-on” wireless services. Rather than relying on the end user to launch special software, establish a connection, gain authorization and download his email periodically, always-on services provide the ability to download email and similar messages to the end user's device automatically when they are received by the service provider, regardless of whether the end user is presently using his mobile device. Always-on therefore provides a user experience similar to hardwired telephones and email on stationary computers: that emails and other data are forwarded to wireless users as they are received by the system. In many cases, announcements are issued by the mobile device when email is received.
A classic problem in mobile wireless environments is how to manage the hand-off of communication sessions from one base station to the next as the mobile user moves around the network, or from one network to another. This problem can be described with respect to the simple block diagram of FIG. 1, where a mobile node 20 is passing from the area served by a radio network 22, to a location 20′ served by radio network 24. Both of the radio networks 22 and 24 are connected to various communication networks such as the public switched telephone network (PSTN) 26 and the Internet (IP Network) 28. (Note that the network of FIG. 1 is a gross simplification, intended simply to present the general handoff problem. The details of an actual implementation would be well known to one skilled in the art.)
The user of the mobile node 20 may, for example, be talking to another party having a hardwired telephone connected to the PSTN 26. When the user of the mobile node 20 moves to position 20′, radio network 24 must pick up the communication without interrupting or dropping the call. The transfer from radio network 22 to radio network 24 is referred to as “handoff” in the art. While it is clearly a sophisticated task, this handoff problem becomes even more difficult when the wireless service is an always-on data service.
In certain wireless data networks, the session handoff between fixed network elements such as radio networks 22 and 24 is initiated by the mobile node 20 rather than the network elements themselves, and there is no communication between the elements of radio networks 22 and 24 concerning the handoff. This is especially true where the mobile node 20 enters a dormant state and then moves into an area covered by a new network element. A “dormant state” is a state in which the mobile device 20 is not sending or receiving data. Email notifications and the like should still be received by the end user's mobile device 20, causing it to transition back to an active state.
For example, the mobile node 20 may have a data session provided by radio network 22 and then enter a dormant state. The mobile node 20 then moves to an area where data coverage is provided by radio network 24. When the mobile node 20 sends out one of its periodic requests for an email update, the request will be received and handled by radio network 24. The radio network 22 may not be notified that a handoff has taken place, thus leaving a stale session on radio network 22 (i.e. radio network 22 is awaiting another message with the current session identifier from the mobile node 20, but the message will never come). The context for this stale session will typically remain on radio network 22 until a pre-configured timeout period has elapsed.
In order to provide for ‘always-on’ services, the pre-configured timeout period mentioned in this example is frequently on the order of hours rather than minutes. This consumes resources unnecessarily on the radio network 22 and other network elements holding the stale session.
As well, this situation significantly complicates the billing process because accounting records for data sessions that span many network elements, must be correlated in order to produce a single record. In always-on systems it is common to bill end users based on the volume of data that they transfer, and also for the amount of time they are connected, even if their mobile unit is in a dormant state. In the scenario described above, where the mobile node 20 has moved from one area to another while in a dormant state, there may be two (or more) radio networks who believe they are providing the always-on connectivity for the mobile node 20. Clearly, only one radio network is really providing this connectivity service at a time, so the conflict must be resolved.
One possible solution to the billing problem is the use of interim accounting records. These records could be sent from the radio networks 22 and 24 at regular intervals following session setup, and report usage metrics for the data session. Using these interim accounting records, a stateful Authentication, Authorization and Accounting (AAA) server could use the session setup event on the new network element to trigger the generation of a billable record based on the last interim accounting record received from the previous network element.
The main disadvantage of this solution is that the sending of the interim accounting record will rarely coincide with the handoff event, so the usage information that would appear in the next interim accounting record is effectively lost. This lost usage information translates to lost revenue for the network operator. The amount of usage lost can be minimized by sending interim accounting records at more frequent intervals but storing and processing these additional accounting records increases the operational costs.
There is therefore a need for a method for session accounting in wireless data networks, in particular, for always-on systems where there is no session handoff communication between the network elements.